Augmenting transport services using real-time event detection

ABSTRACT

A method for augmenting transport services using event detection is provided. The method includes collection of first sensor data generated by various sensors associated with a plurality of vehicles. The first sensor data includes sensor outputs that indicate a plurality of rash driving events. The sensor outputs are augmented based on angular rotation to obtain augmented sensor outputs. A prediction model is trained based on the augmented sensor outputs. Target sensor data associated with a target vehicle is provided as input to the trained prediction model, and based on an output of the trained prediction model an occurrence of a rash driving event is detected in real-time or near real-time. Based on a count of rash driving events associated with the target driver within a cumulative driving distance, a driver score of the target driver is determined.

CROSS-RELATED APPLICATIONS

This application claims priority of Indian Non-Provisional ApplicationNo. 202041046254, filed Oct. 23, 2020, the contents of which areincorporated herein by reference.

FIELD

Various embodiments of the disclosure relate generally to transportservices. More specifically, various embodiments of the disclosurerelate to methods and systems for augmenting transport services usingevent detection.

BACKGROUND

With proliferation of the Internet, on-demand transport services havebecome increasingly popular. As a result, individuals often rely onthese on-demand transport services to fulfill their travelling needs.These services not only cater to the travelling needs of individuals butalso allow individuals to participate in the role of drivers as well.For example, many transport services enable individuals serving asdrivers to provide transport for other individuals and deliver packages,goods, prepared foods, or the like.

Typically, driving styles of drivers have a great impact on the healthof vehicles they drive and the overall travel experience of passengers.For example, congenial driving style of a driver may lead to safe andsatisfactory travelling experience for passengers and assure longevityof the corresponding vehicle. However, many a times drivers incorporatesubstandard driving styles. For example, an aggressive driver mayfrequently exhibit rash driving style such as harsh braking, harshacceleration, harsh corning, or the like. Such rash driving styles leadto a poor travel experience for the passengers and may even lead toaccidents, hence putting the life of the passengers at jeopardy.Further, such rash driving styles often damage the vehicles, leading toincreased repair and maintenance cost for the vehicles and reducedlifespan of the vehicles, which is undesirable.

Thus, there exists a need for monitoring and analyzing the drivingstyles of the drivers for averting the above-mentioned problems. A knownapproach for monitoring and analyzing the driving styles of the driversinvolves periodic inspection of the health of the vehicles and obtainingregular feedback from the passengers on their travel experience.However, periodic inspection and feedback collection are typicallyperformed after the termination of a ride, and hence, fail to providepassenger satisfaction during their travel and avert catastrophicincidents, for example, accidents, in real time or near real-time basis.

In the light of the foregoing, there exists a need for a technical andreliable solution that overcomes the above-mentioned problems, andensures efficient monitoring and analyzing of driving styles of driverson a real-time or near real-time basis.

SUMMARY

Methods and systems for augmenting transport services using eventdetection are provided substantially as shown in, and described inconnection with, at least one of the figures, as set forth morecompletely in the claims.

These and other features and advantages of the present disclosure may beappreciated from a review of the following detailed description of thepresent disclosure, along with the accompanying figures in which likereference numerals refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that illustrates an exemplary environment foraugmenting transport services using event detection, in accordance withan exemplary embodiment of the disclosure;

FIG. 2 is a block diagram that illustrates a vehicle of FIG. 1, inaccordance with an exemplary embodiment of the disclosure;

FIG. 3 is a schematic diagram that illustrates an exemplary scenario fortraining a prediction model for event detection, in accordance with anexemplary embodiment of the disclosure;

FIGS. 4A and 4B, collectively represent a process-flow diagram thatillustrates an exemplary scenario for event detection and driverprofiling in real-time or near real-time, in accordance with anexemplary embodiment of the disclosure;

FIG. 5 is a block diagram that illustrates an application server of FIG.1, in accordance with an exemplary embodiment of the disclosure;

FIG. 6A is a flow chart that illustrates a method for training aprediction model for rash driving event detection, in accordance with anexemplary embodiment of the disclosure;

FIG. 6B is a sub flow chart that illustrates a method for augmenting aplurality of sensor outputs, in accordance with an exemplary embodimentof the disclosure;

FIGS. 7A and 7B collectively, represent a flow chart that illustrates amethod for augmenting transport services using real-time eventdetection, in accordance with an exemplary embodiment of the disclosure;

FIG. 8 is a flow chart that illustrates a method of authenticating adriver of a vehicle, in accordance with an embodiment of the presentdisclosure;

FIG. 9 is a flow chart that illustrates a method for training aprediction model for rash driving event detection, in accordance with anexemplary embodiment of the disclosure;

FIGS. 10A and 10B collectively, represent a flow chart that illustratesa method for augmenting transport services using real-time eventdetection, in accordance with an exemplary embodiment of the disclosure;and

FIG. 11 is a block diagram that illustrates a system architecture of acomputer system for augmenting transport services using real-time eventdetection, in accordance with an exemplary embodiment of the disclosure.

DETAILED DESCRIPTION

Certain embodiments of the disclosure may be found in disclosed systemsand methods for augmenting transport services using event detection.Exemplary aspects of the disclosure provide methods and systems foraugmenting the transport services using event detection and driverprofiling. The methods and systems include various operations that areexecuted by a server (for example, an application server) to augment thetransport services using event detection and driver profiling. In anembodiment, the server may be configured to collect first sensor datafrom a plurality of sensors associated with a plurality of vehicles. Thefirst sensor data includes a first plurality of sensor outputs thatindicate a plurality of rash driving events. The server may beconfigured to augment the first plurality of sensor outputs based onangular rotation to obtain a plurality of augmented sensor outputs. Theserver may be configured to train a prediction model based on theplurality of augmented sensor outputs. The server may be configured toreceive, in real-time or near real-time, target sensor data from one ormore sensors associated with a target vehicle driven by a target driver.The target sensor data includes a second plurality of sensor outputsthat indicate a first driving pattern of the target driver at a firsttime-instance. The server may be configured to provide the target sensordata to the trained prediction model as an input. In an embodiment, theone or more sensors may be included in a mobile device that is presentinside the target vehicle while the target vehicle is driven by thetarget driver. In such an embodiment, the server may provide the targetsensor data to the trained prediction model only when the mobile deviceis detected to be stable. Based on an output of the trained predictionmodel for the inputted target sensor data, the server may be configuredto detect an occurrence of at least one of the plurality of rash drivingevents at the first time-instance. The server may be further configuredto determine a driver score for the target driver based on the detectedrash driving event at the first time-instance and one or more rashdriving events associated with the target driver in the past. The servermay be further configured to categorize a driving style of the targetdriver in one of a plurality of driving style categories based on thedetermined driver score of the target driver. The server may be furtherconfigured to communicate an alert notification to the communicationdevice of the target driver when the driver score of the target driveris below a threshold driver score.

The method and systems of the disclosure provide a technical solutionthat detects real-time rash driving events for vehicles, withoutrequiring the vehicles to be equipped with additional or specializedhardware. Further, based on the rash driving event detection, driversare categorized and real time alerts and warnings are communicated tothe drivers. Such real time alerts and warnings enable reshaping ofsubstandard driving styles to optimal driving styles. Thus, the methodsand systems of the present disclosure are not only capable of detectingrash driving events but also correcting substandard driving styles ofdrivers on real-time or near real-time basis.

FIG. 1 a block diagram that illustrates an exemplary environment 100 foraugmenting transport services using event detection, in accordance withan embodiment of the present disclosure. The exemplary environment 100includes a first driver 102, a first communication device 104, a firstvehicle 106 driven by the first driver 102, a second driver 108, asecond communication device 110, and a second vehicle 112 driven by thesecond driver 108. The exemplary environment 100 further includes anapplication server 114 and a database server 116. The exemplaryenvironment 100 further includes a target driver 118, a thirdcommunication device 120, and a target vehicle 122 being driven by thetarget driver 118. The first through third communication devices 104,110, and 120, the application server 114, and the database server 116may communicate with each other by way of a communication network 124 orthrough separate communication channels therebetween. In an embodiment,the first and second vehicles 106 and 112 and the target vehicle 122 maybe coupled to the communication network 124 via one of telematicsdevices, on-board diagnostics devices (OBD), the first through thirdcommunication devices 104, 110, and 120, or a connected car networkhandled by a third-party server. For the sake of brevity, the systemenvironment 100 is shown to include only three vehicles (i.e., the firstvehicle 106, the second vehicle 112, and the target vehicle 122).However, in actual implementation, the exemplary environment 100 mayinclude multiple vehicles of different makes, models, age, or the like,without deviating from the scope of the disclosure.

The first communication device 104 may be a computing device that ispresent within (or inside) the first vehicle 106, while the firstvehicle 106 is being driven by the first driver 102. The firstcommunication device 104 may include suitable logic, circuitry,interfaces, sensors, and/or code, executable by the circuitry to performone or more data collection and communication operations. Examples ofthe first communication device 104 may include, but are not limited to,a mobile phone, a smartphone, a tablet, a phablet, a laptop, a computer,a telematics device, an OBD device, a multi-tainment system, and avehicle head unit. In an embodiment, the first communication device 104may be communicatively coupled to a plurality of sensors of the firstvehicle 106 for obtaining sensor data generated by the plurality ofsensors with regards to the motion of the first vehicle 106. In anotherembodiment, the first communication device 104 may include varioussensors that generate sensor data. Since the first communication device104 is within the first vehicle 106, the sensor data generated by thesensors of the first communication device 104 is indicative of themotion of the first vehicle 106. The first communication device 104 maybe further configured to communicate the sensor data to the applicationserver 114. In one embodiment, the first communication device 104 may beconfigured to run a service application hosted by the application server114, such that the service application serves as a communication gatewaybetween the application server 114 and the first communication device104. The first communication device 104 may be a stationary device thatis affixed to the first vehicle 106 or a mobile device.

The first vehicle 106 may be a mode of transport and may includesuitable logic, circuitry, interfaces and/or code, executable by thecircuitry, that may be configured to control and perform one or moreoperations with driving assistance from the first driver 102. In anembodiment, the first vehicle 106 may be deployed by a transport serviceprovider (e.g., a cab service provider) to cater to travellingrequirements of various passengers. In another embodiment, the firstvehicle 106 may be a personal vehicle of the first driver 102 or anindividual who has hired or employed the first driver 102 for drivingassistance. Examples of the first vehicle 106 may include, but are notlimited to, an automobile, a bus, a car, an auto rickshaw, and a bike.In an embodiment, the first vehicle 106 may include the plurality ofsensors (as shown in FIG. 2) that are configured to generate the sensordata pertaining to (or characterizing) the motion of the first vehicle106. In one embodiment, the first vehicle 106 may be an electricvehicle.

The second communication device 110 may be a computing device that ispresent within or inside the second vehicle 112, while the secondvehicle 112 is being driven by the second driver 108. Examples of thesecond communication device 110 may include, but are not limited to, amobile phone, a smartphone, a tablet, a phablet, a laptop, a computer, atelematics device, an OBD device, a multi-tainment system, and a vehiclehead unit. The second communication device 110 is functionally similarto the first communication device 104.

The second vehicle 112 is a mode of transport and may include suitablelogic, circuitry, interfaces and/or code, executable by the circuitry,that may be configured to control and perform one or more operationswith driving assistance from the second driver 108. Examples of thesecond vehicle 112 may include, but are not limited to, an automobile, abus, a car, an auto rickshaw, and a bike. The second vehicle 112 isfunctionally similar to the first vehicle 106. In one embodiment, thesecond vehicle 112 may be an electric vehicle.

The application server 114 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry, that may beconfigured to perform one or more operations for real-time eventdetection and driver profiling. The application server 114 may beconfigured to communicate with the first through third communicationdevices 104, 110, and 120, and the database server 116 via thecommunication network 124. Examples of the application server 114 mayinclude a cloud-based server, a local server, a group of centralizedservers, a group of distributed servers, or the like. In an embodiment,the application server 114 may be a standalone system as shown in FIG. 1for real-time event detection and driver profiling. In anotherembodiment, the application server 114 may be implemented as asub-system or component of a transport arrangement system. Theapplication server 114 may be configured to operate in two phases (ormodes) such as a training phase and an implementation phase.

During the training phase, the application server 114 may be configuredto collect first sensor data generated by sensors associated with aplurality of vehicles (e.g., the first and second vehicles 106 and 112).The collected first sensor data may include a first plurality of sensoroutputs that indicate a plurality of rash driving events. Examples ofthe rash driving events may include, but are not limited to, a harshbraking event, a harsh cornering event, a harsh acceleration event, aharsh bump event, a tailgating event, and an over-speeding event. Inother words, the collected first sensor data is tagged for various rashdriving events associated with the first and second vehicles 106 and112. The application server 114 may be configured to augment the firstplurality of sensor outputs based on angular rotation to obtain aplurality of augmented sensor outputs. The application server 114 may befurther configured to train a first prediction model 126 based on theplurality of augmented sensor outputs for rash driving event detection.Examples of the first prediction model 126 may include but are notlimited to, a Support Vector Machine (SVM), a Logistic Regression model,a Bayesian classifier, a Decision Tree Classifier, a Copula-based model,a K-Nearest Neighbors (KNN) Classifier, an Artificial Neural Network(ANN), a Deep Feed Forward network, a Deep Convolutional network, aRecurrent Neural network, a Long Short Term Memory (LSTM) network, or aRandom Forest (RF) classifier. After the first prediction model 126 istrained, the application server 114 may operate in the implementationphase.

During the implementation phase, the application server 114 may beconfigured to receive, in real-time or near real-time, target sensordata (i.e., second sensor data) generated by sensors associated with thetarget vehicle 122. In an embodiment, the sensors that generate thetarget sensor data are a part of the target vehicle 122. In anotherembodiment, the sensors that generate the target sensor data areincluded in the third communication device 120 that is present withinthe target vehicle 122. Examples of the third communication device 120may include, but are not limited to, a mobile phone, a smartphone, atablet, a phablet, a laptop, a computer, a telematics device, an OBDdevice, a multi-tainment system, and a vehicle head unit. The targetsensor data includes a second plurality of sensor outputs that indicate(or characterize) a motion of the target vehicle 122. The applicationserver 114 may be configured to provide the received target sensor dataas an input to the trained first prediction model 126. Based on theinputted target sensor data, the trained first prediction model 126 maygenerate an output to indicate a likelihood of the target vehicle 122being associated with one of the plurality of rash driving events. Thus,based on the output of the trained first prediction model 126, theapplication server 114 may detect an occurrence of at least one of theplurality of rash driving events for the target vehicle 122. Theapplication server 114 may be further configured to generate adriving-pattern profile of the target driver 118 based on the targetsensor data aggregated or accumulated over a continuous time interval,e.g., a week, a month, or the like. The driving-pattern profile of thetarget driver 118 may quantify one or more driver characteristics of adriving pattern of the target driver 118. The application server 114 mayfurther analyze a past driving behavior of the target driver 118 inconjunction with the recently detected rash driving event and generate adriver score for the target driver 118. In an embodiment, if the driverscore of the target driver 118 is less than or equal to a thresholddriver score, the application server 114 may communicate an alertnotification to the third communication device 120 of the target driver118. The application server 114 may be further configured to select onea plurality of outcomes (e.g., penalizing or incentivizing a driver) forthe target driver 118 based on the determined driver score.

The database server 116 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry, that may beconfigured to perform one or more operations for storing driver profilesof various drivers (e.g., the first and second drivers 102 and 108, andthe target driver 118). A driver profile of a driver may be indicativeof a past driving behavior of the driver and may include a count of rashdriving events that have been detected for the driver, a driving-patternprofile of the driver as determined by the application server 114, andoperational data of various vehicles that have been driven by thedriver. In an embodiment, the driver profiles of the drivers may bestored in the database server 116 by the application server 114.

The application server 114 may be configured to update the driverprofiles of the drivers based on sensor data associated with vehiclesdriven by these drivers. Examples of the database server 116 may includea cloud-based database, a local database, a distributed database, adatabase management system (DBMS), or the like. Although the applicationserver 114 and the database server 116 are shown as standalone entitiesin FIG. 1, it will be apparent to a person of ordinary skill in the artthat, in another embodiment, the functionalities of the database server116 v may be integrated with the application server 114, withoutdeviating from the scope of the disclosure.

Examples of the communication network 124 may include, but are notlimited to, a wireless fidelity (Wi-Fi) network, a light fidelity(Li-Fi) network, a local area network (LAN), a wide area network (WAN),a metropolitan area network (MAN), a satellite network, the Internet, afiber optic network, a coaxial cable network, an infrared (IR) network,a radio frequency (RF) network, and a combination thereof. Variousentities (such as the first through third communication devices 104,110, and 120, the database server 116, and the application server 114),in the exemplary environment 100 may be coupled to the communicationnetwork 124 in accordance with various wired and wireless communicationprotocols, such as Transmission Control Protocol and Internet Protocol(TCP/IP), User Datagram Protocol (UDP), Long Term Evolution (LTE)communication protocols, or any combination thereof.

In operation, the sensors associated with the first and second vehicles106 and 112 may generate sensor data based on one or more movementcharacteristics of the first and second vehicles 106 and 112. The firstand second communication devices 104 and 110 may communicate thegenerated sensor data to the application server 114 over thecommunication network 124. The application server 114 may be configuredto collect the received sensor data over a first time-interval. Thesensor data collected by the application server 114 over the firsttime-interval may be referred to as “the first sensor data”. The firstsensor data may include the first plurality of sensor outputs thatindicate the plurality of rash driving events experienced by the firstand second vehicles 106 and 112 during the first time-interval. Theapplication server 114 may be configured to augment the first pluralityof sensor outputs based on angular rotation to obtain the plurality ofaugmented sensor outputs. The application server 114 may further trainthe first prediction model 126 based on the plurality of augmentedsensor outputs for rash driving event detection. When the target vehicle122 is traversing a route, the sensors associated with the targetvehicle 122 may generate the target sensor data to characterize themovement (or motion) of the target vehicle 122. The third communicationdevice 120 that is placed within the target vehicle 122 may communicatethe generated target sensor data to the application server 114. Theapplication server 114 may receive the target sensor data from the thirdcommunication device 120 over the communication network 124 and providethe received target sensor data as an input to the trained firstprediction model 126. Based on the inputted target sensor data, thetrained first prediction model 126 may generate an output to indicate alikelihood of the target vehicle 122 being associated with one of theplurality of rash driving events. Thus, based on the output of thetrained first prediction model 126, the application server 114 maydetect an occurrence of at least one of the plurality of rash drivingevents for the target vehicle 122. The application server 114 mayfurther communicate an alert notification to the third communicationdevice 120 of the target driver 118. Such real-time alert notificationsupon detection of the rash driving events enable the application server114 to incorporate re-enforcement learning principles for modeling thedriving style and behavior of the target driver 118.

FIG. 2 is a block diagram 200 that illustrates the first vehicle 106, inaccordance with an exemplary embodiment of the disclosure. As shown inFIG. 2, the first vehicle 106 is being driven by the first driver 102,while a passenger 202 is seated on a back seat of the first vehicle 106.In another example, the first driver 102 may be the sole occupant of thefirst vehicle 106. The first vehicle 106 includes the plurality ofsensors that sense one or more characteristics of the motion of thefirst vehicle 106. The plurality of sensors may include an accelerometer204 a, a gyroscope 204 b, a magnetometer 204 c, an altimeter 204 d, agravity sensor 204 e, or the like. It will be apparent to a person ofordinary skill in the art that the first vehicle 106 may includemultiple other motion sensors that sense the characteristics of themotion of the first vehicle 106. Hereinafter, the plurality of sensorsare referred to and designated as “the plurality of sensors 204”. In oneembodiment where the first vehicle 106 is an electric vehicle, the firstvehicle 106 may further include one or more batteries 206 (hereinafter,referred to as “the batteries 206”) to power the first vehicle 106 and abattery management system (BMS) 208.

The accelerometer 204 a is a motion sensor that is configured to detectand measure acceleration of the first vehicle 106 and generate a sensoroutput (i.e., sensor data) based on the detection. The accelerometer 204a may be a three-axes accelerometer, thus, each sensor output generatedby the accelerometer 204 a includes three axes sensor values along firstthrough third axes, respectively, for example, along X-axis, Y-axis, andZ-axis.

The gyroscope 204 b is a motion sensor that is configured to detect andmeasure orientation and angular velocity of the first vehicle 106 andgenerate a sensor output (i.e., sensor data) based on the detection. Thegyroscope 204 b may be a three-axes gyroscope, thus, each sensor outputgenerated by the gyroscope 204 b includes three axes sensor values alongthe first through third axes, respectively, for example, along X-axis,Y-axis, and Z-axis.

The magnetometer 204 c is a motion sensor that is configured to detectand measure the orientation of the first vehicle 106 relative to theEarth's magnetic north and generate a sensor output (i.e., sensor data)based on the detection. The magnetometer 204 c may be a three-axesmagnetometer, thus, each sensor output generated by the magnetometer 204c includes three axes sensor values along first through third axes,respectively, for example, along X-axis, Y-axis, and Z-axis.

The altimeter 204 d is a motion sensor that is configured to detect andmeasure elevation or altitude of the first vehicle 106 and generate asensor output (i.e., sensor data) based on the detection. The altimeter204 d may be a three-axes altimeter, thus, each sensor output generatedby the altimeter 204 d includes three axes sensor values along the firstthrough third axes, respectively, for example, along X-axis, Y-axis, andZ-axis.

The gravity sensor 204 e is a motion sensor that is configured to detectand measure an acceleration effect of the Earth's gravity on the firstvehicle 106 and generate a sensor output (i.e., sensor data) based onthe detection. The gravity sensor 204 e may be a three-axes gravitysensor, thus, each sensor output generated by the gravity sensor 204 eincludes three axes sensor values along the first through third axes,respectively, for example, along X-axis, Y-axis, and Z-axis.

When the first vehicle 106 is in motion, the plurality of sensors 204generate corresponding sensor outputs based on the characteristics ofthe motion. The characteristics of the motion may include, but are notlimited to, velocity, acceleration, tilt, elevation, or the like. Theplurality of sensors 204 may be further configured to communicate thegenerated sensor outputs to the first communication device 104.

Similarly, the second vehicle 112 and the target vehicle 122 are alsoassociated with a corresponding plurality of sensors that are similar tothe plurality of sensors 204. Although the plurality of sensors 204 areshown to be a part of the first vehicle 106, the scope of disclosure isnot limited it. In another embodiment, the first communication device104 may include the plurality of sensors 204 without deviating from thescope of the disclosure.

The batteries 206 are energy storage devices that may be configured topower or supply current to one or more components of the first vehicle106 for the functioning of the first vehicle 106. The batteries 206 mayget drained upon usage, and may require periodic charging for thefunctioning of the first vehicle 106. Examples of the batteries 206 mayinclude, but are not limited to, a lead acid battery, a Nickel Cadmium(NiCd) battery, a Nickel Metal Hydride (NIMH) battery, a lithium ionbattery, a zinc air battery, or the like. The batteries 206 may bemanaged by the BMS 208.

The BMS 208 may include suitable logic, circuitry, interfaces, and/orcode, executable by the circuitry, that may be configured to perform oneor more operations for monitoring and managing the batteries 206. TheBMS 208 may be communicatively coupled to the batteries 206 via a wiredconnection (such as an auxiliary cable, ethernet, hardware controlledarea network (CAN) bus, or the like) or a wireless connection. The BMS208 may be configured to monitor a state of charge (i.e., a chargelevel) of the batteries 206. The BMS 208 may include one or more sensorsthat generate sensor data to indicate an amount of current beingsupplied by the batteries 206 for the functioning of the first vehicle106. The BMS 208 may be further configured to communicate the generatedsensor data to the first communication device 104. Examples of the BMS208 may include application-specific integrated circuit (ASIC)processor, a reduced instruction set computing (RISC) processor, acomplex instruction set computing (CISC) processor, and afield-programmable gate array (FPGA). It will be apparent to a person ofordinary skill in the art that the BMS 208 may be compatible withmultiple operating systems.

FIG. 3 is a schematic diagram that illustrates an exemplary scenario 300for training the first prediction model 126 for event detection, inaccordance with an exemplary embodiment of the disclosure. For the sakeof brevity, training data has been shown to correspond to a sample sizeof two (i.e., two vehicles 106 and 112). However, in an actualimplementation, the training data may correspond to a large sample size(e.g., a sample size of a thousand vehicles, ten thousand vehicles, or amillion vehicles).

In the training phase, the first and second drivers 102 and 108 may beinstructed, by the application server 114 via the respective first andsecond communication devices 104 and 110, to simulate the plurality ofrash driving events using the respective first and second vehicles 106and 112. Examples of the plurality of rash driving events may include,but are not limited to, a harsh braking event, a harsh cornering event,a harsh acceleration event, a harsh bump event, a tailgating event, andan over-speeding event. Further, the first and second communicationdevices 104 and 110 may be placed at a default angular position (ororientation along X-axis, Y-axis, and Z-axis) in the respective firstand second vehicles 106 and 112. When the plurality of rash drivingevents are simulated using the first and second vehicles 106 and 112,the sensors in the first and second communication devices 104 and 110generate sensor outputs (i.e., the first plurality of sensor outputs)indicating the plurality of rash driving events. For example, when aharsh braking event is simulated using the first vehicle 106, thesensors of the first communication device 104, that is present withinthe first vehicle 106, generate sensor outputs indicating the harshbraking event. Further, the sensor outputs that indicate the harshbraking event may be spread across multiple sequential timestamps. Forexample, if the simulation of harsh braking event is spanned across 5seconds, the sensors generate sequential sensor outputs for 5 secondsthat collectively indicate the harsh braking event. In an embodiment,each sensor output may include three axes sensor values along the firstthrough third axis (i.e., X-axis, Y-axis, and Z-axis). For example, afirst sensor output may be (p₁, p₂, p₃), where p₁, p₂, and p₃ correspondto sensor values along X-axis, Y-axis, and Z-axis, respectively. Inanother embodiment, when the plurality of rash driving events aresimulated using the first and second vehicles 106 and 112, the sensorsincluded in the first and second vehicles 106 and 112 generate thesensor outputs indicating the plurality of rash driving events. Forexample, when a harsh braking event is simulated using the first vehicle106, the plurality of sensors 204 generate sensor outputs that indicatethe harsh braking event. The sensor outputs (i.e., the first pluralityof sensor outputs) generated by the sensors included in the first andsecond vehicles 106 and 112 are then communicated to the respectivefirst and second communication devices 104 and 110. In an embodiment,each rash driving event may be simulated multiple times by the first andsecond drivers 102 and 108 on the respective first and second vehicles106 and 112.

The first and second communication devices 104 and 110 communicate thesensor outputs to the application server 114. Thus, during the trainingphase, the application server 114 may be configured to receive andcollect the first sensor data, including the first plurality of sensoroutputs, from the first and second communication devices 104 and 110. Inother words, the first sensor data includes acceleration data, gravitysensor data, gyroscopic data, altimeter data, and/or magnetometer data.The application server 114 may utilize the collected first sensor datafor training the first prediction model 126. In other words, the firstsensor data, that is labeled for the plurality of rash driving events,may serve as a training dataset (or corpus) for training the firstprediction model 126.

After the collection of the first sensor data, the application server114 may be configured to augment the first plurality of sensor outputsbased on random angular rotation. For example, a sensor value (along anyof the X-axis, Y-axis, and Z-axis) of a sensor output may be rotated inthe range (−180 deg, 180 deg) based on clockwise or anticlockwiserotation. For augmenting the first plurality of sensor outputs, theapplication server 114 may be configured to generate an ‘N×3’3-dimensional (3D) rotation matrix (R(N×3)). The three columns of the 3Drotation matrix (R_((N×3))) correspond to the respective X-axis, Y-axis,and Z-axis, and each row of the 3D rotation matrix (R_((N×3)))corresponds to a random angular rotation along X-axis, Y-axis, andZ-axis. For generating the 3D rotation matrix (R_((N×3))), theapplication server 114 may be configured to randomly choose ‘N’ angularpositions (e.g., three random positions a₁, a₂, and a₃) and determinevalues for angular rotations along X-axis, Y-axis, and Z-axis to achievethe randomly chosen angular positions. For example, for achieving theangular position al from the default angular position, a sensor outputmight be required to be rotated 30 degrees clockwise along X-axis, 50degrees anticlockwise along Y-axis, 0 degrees along Z-axis. Thus, thefirst row of the 3D rotation matrix (R_((N×3))) corresponding to theangular position al may have values (30 deg, −50 deg, and 0 deg).Similarly, the application server 114 may determine the remaining rowsof the 3D rotation matrix (R_((N×3))). The application server 114 may befurther configured to apply the generated 3D rotation matrix (R_((N×3)))to each sensor output in the first sensor data to obtain the pluralityof augmented sensor outputs. Thus, for each sensor output, ‘N’ augmentedsensor outputs are obtained those indicate the same rash driving eventsas the corresponding sensor output indicated before augmentation. Forexample, if the first sensor output indicates the harsh accelerationevent, the ‘N’ augmented sensor outputs obtained from the first sensoroutput also indicate the harsh acceleration event. In an embodiment, thethree axis sensor values of a sensor output may be modified due to theangulation rotation by way of the 3D rotation matrix (R_((N×3))).

After the augmentation of the first plurality of sensor outputs, theapplication server 114 may be configured to train the first predictionmodel 126 using the plurality of augmented sensor outputs. Theapplication server 114 may implement any suitable machine-learningtechniques, statistical techniques, deep learning, or probabilistictechniques for training of the first prediction model 126. Based on thetraining, the first prediction model 126 learns an association betweenthe augmented sensor outputs and the plurality of rash driving events.For example, the first prediction model 126 may learn, from theplurality of augmented sensor outputs, an acceleration range or patternthat corresponds to the harsh acceleration event. In another example,the first prediction model 126 may learn, from the plurality ofaugmented sensor outputs, a deacceleration range or pattern thatcorresponds to the harsh braking event. Beneficially, training the firstprediction model 126 using the plurality of augmented sensor outputsgeneralizes the first prediction model 126. In other words, the firstprediction model 126 is trained to be agnostic of any angular positionassociated with sensor outputs. Thus, a prediction accuracy of thetrained first prediction model 126 is not impacted by variations in theplacement or orientation of communication devices that include thesensors for generating sensor outputs.

After the first prediction model 126 is trained, the application server114 may be configured to validate an accuracy level of the trained firstprediction model 126. For validation, the application server 114 mayprovide a batch of sensor outputs as an input to the trained firstprediction model 126. The batch of sensor outputs may be associated witha known rash driving event. Based on the inputted batch of sensoroutputs, the first prediction model 126 may generate an output thatindicates a likelihood of occurrence of the known rash driving event.The application server 114 may be configured to compare the output ofthe first prediction model 126 with an actual result and generate avalidation output, i.e., the application server 114 may determinewhether the first prediction model 126 has accurately predicted theoccurrence of the known rash driving event. The validation output may beused as a feedback to improve the accuracy level of the first predictionmodel 126.

After the first prediction model 126 is trained, the application server114 may execute the implementation phase. In the implementation phase,the application server 114 may utilize the first prediction model 126 todetect occurrences of one or more rash driving events based on real-timesensor data. The implementation phase has been described in detail inconjunction with FIGS. 4A and 4B. In another embodiment, theimplementation phase may be executed in a separate system, device, orserver. In such a scenario, the application server 126 may be configuredto communicate the trained first prediction model 126 to the otherserver for executing the implementation phase.

In another embodiment, the first and second vehicles 106 and 112 may beelectric vehicles. In such an embodiment, during the training phase whenthe first and second drivers 102 and 108 simulate the plurality of rashdriving events using their respective first and second vehicles 106 and112, BMSs of the first and second vehicles 106 and 112 may record sensordata indicating an amount of current being supplied by batteries of thefirst and second vehicles 106 and 112. For example, the sensors of theBMS 208 may generate sensor data that indicates the amount of currentbeing supplied by the batteries 206 while the first driver 102 simulatesthe plurality of rash driving events on the first vehicle 106. The BMSsmay further communicate the generated sensor data (i.e., recorded amountof current) to the respective first and second communication devices 104and 110. The first and second communication devices 104 and 110 mayfurther communicate the received sensor data to the application server114. The application server 114 may be configured to collect the sensordata for the first time-interval. The collected sensor data pertainingto the amount of current being supplied by the batteries of the firstand second vehicles 106 and 112 is indicative of a pattern of currentusage associated with each of the plurality of rash driving events. Theapplication server 114 may be configured to utilize the collected sensordata for training a second prediction model 302. In another embodiment,the application server 114 may utilize the collected sensor data for thefurther training of the first prediction model 126. For the sake ofbrevity, it is assumed that the application server 114 utilizes thecollected sensor data to train the second prediction model 302. Examplesof the second prediction model 302 may include but are not limited to,an SVM based model, a Logistic Regression model, a Bayesian classifier,a Decision Tree Classifier, a Copula-based model, a KNN Classifier, anANN, a Deep Feed Forward network, a Deep Convolutional network, aRecurrent Neural network, an LSTM network, or an RF classifier.

The application server 114 may implement any suitable machine-learningtechniques, statistical techniques, deep learning, or probabilistictechniques for training the second prediction model 302. Based on thetraining, the second prediction model 302 learns an association betweenthe current usage pattern and the plurality of rash driving events. Forexample, the second prediction model 302 may learn, from the collectedsensor data, a first current usage (or supply) pattern for the harshacceleration event. In another example, the second prediction model 302may learn, from the collected sensor data, a second current usage (orsupply) pattern that corresponds to the harsh braking event.Beneficially, training the second prediction model 302 using the sensordata collected from a variety of batteries having differentconfiguration, make, current supply capacity, or the like generalizesthe second prediction model 302. In other words, the second predictionmodel 302 is trained to be agnostic of any battery type. Thus, aprediction accuracy of the trained second prediction model 302 is notimpacted by variation in the types of batteries.

After the second prediction model 302 is trained, the application server114 may be configured to validate an accuracy level of the trainedsecond prediction model 302. For validation, the application server 114may provide current usage (or supply) data of the batteries 206 as aninput to the trained second prediction model 302. The current usage (orsupply) data may be associated with a known rash driving event. Based onthe inputted current usage (or supply) data, the second prediction model302 may generate an output that indicates a likelihood of occurrence ofthe known rash driving event. The application server 114 may beconfigured to compare the output of the second prediction model 302 withan actual result and generate a validation output, i.e., the applicationserver 114 may determine whether the second prediction model 302 hasaccurately predicted the occurrence of the known rash driving event. Thevalidation output may be used as a feedback to improve the accuracylevel of the second prediction model 302.

After the second prediction model 302 is trained, the application server114 may execute the implementation phase. In the implementation phase,the application server 114 may utilize the second prediction model 302along with the first prediction model 126 to detect occurrences of oneor more rash driving events.

FIGS. 4A and 4B, collectively represent a process-flow diagram 400 thatillustrates an exemplary scenario for event detection and driverprofiling in real-time or near real-time, in accordance with anexemplary embodiment of the disclosure.

With reference to FIG. 4A, the target vehicle 122 may be driven by thetarget driver 118. While the target vehicle 122 is being driven by thetarget driver 118, the third communication device 120 may be presentwithin the target vehicle 122. Since the third communication device 120is present within a moving vehicle, the third communication device 120also experiences the same motion as the target vehicle 122. Thus, thesensors (e.g., an accelerometer, a gyroscope, a magnetometer, analtimeter, and/or a gravity sensor) of the third communication device120 may sense the motion and generate sensor outputs that characterizethe motion of the target vehicle 122. In an embodiment, the thirdcommunication device 120 may be a stationary device that is affixed tothe target vehicle 122. In such an embodiment, the third communicationdevice 120 may only experience the motion of the target vehicle 122 andmay not be subjected to any additional movement due to the handling ofthe third communication device 120. In another embodiment, the thirdcommunication device 120 may be a mobile device that is not affixed tothe target vehicle 122. Thus, the third communication device 120 may besubjected to additional movements when the third communication device120 is handled by the target driver 118 or any other occupant of thetarget vehicle 122. Thus, in such a scenario, the sensor outputsgenerated by the sensors of the third communication device 120 maycharacterize the motion of the target vehicle 122 as well as theadditional movements of the third communication device 120. In anembodiment, the third communication device 120 may be configured to runthe service application hosted by the application server 114. Forexample, the target vehicle 122 may be deployed by a transportaggregator offering an on-demand transport service. In such a scenario,the service application running on the third communication device 120may correspond to a driver application for the on-demand transportservice. The third communication device 120 may communicate real-time ornear real-time target sensor data (i.e., the second sensor data)generated by the corresponding sensors to the application server 114 byway of the service application (as shown by arrow 402). The targetsensor data includes the sensor outputs (i.e., the second plurality ofsensor outputs) generated by the sensors of the third communicationdevice 120 due to a motion experienced by the third communication device120. The second plurality of sensor outputs indicate a driving patternof the target driver 118 driving the target vehicle 122 at the currenttime-instance.

The application server 114 may be configured to receive the targetsensor data communicated by the third communication device 120. Uponreceiving the target sensor data, the application server 114 may beconfigured to detect whether the third communication device 120 fromwhich the target sensor data is received is stable or unstable (as shownby arrow 404). For detecting whether the third communication device 120is stable or unstable, the application server 114 may be configured toutilize the sensor outputs of the gyroscopic sensor or the gravitysensor in the received target sensor data.

In an exemplary scenario, a sensor output generated by the gyroscopicsensor at the current time-instance t₁ may include 3-axes sensor valuesG (g₁, g₂, g₃). The application server 114 may be configured to derive afirst metric M₁ based on the sensor output G (g₁, g₂, g₃). In oneexample, the first metric M₁ may be derived based on the equation (1) asshown below:

$\begin{matrix}{M_{1} = \left( {g_{1}^{2} + g_{2}^{2} + g_{3}^{2}} \right)^{0.5}} & (1)\end{matrix}$

When the derived first metric M₁ satisfies a first predefined condition,the application server 114 may detect that the third communicationdevice 120 is stable. However, when the derived first metric M₁ does notsatisfy the first predefined condition, the application server 114 maydetect that the third communication device 120 is unstable. In anexemplary scenario, when the derived first metric M₁ is less than equalto a first value (i.e., M₁≤n), the application server 114 detects thatthe third communication device 120 is stable. However, when the derivedfirst metric M₁ is greater than the first value (i.e., M₁>n), theapplication server 114 detects that the third communication device 120is unstable. The first value may be determined by the application server114 based on historical gyroscopic sensor data collected from variousstable and unstable communication devices.

In another exemplary scenario, a first sensor output generated by thegravity sensor at the current time-instance t₁ may be GR₁ (gr₁, gr₂,gr₃) and a second sensor output generated by the gravity sensor at aprevious time instance may be GR₂ (gr₅, gr₆, gr₇). The applicationserver 114 may be configured to derive a second metric M₂ based on thesensor outputs GR₁ (gr₁, gr₂, gr₃) and GR₂ (gr₅, gr₆, gr₇). In oneexample, the second metric M₂ may be derived based on the equation (2)as shown below:

$\begin{matrix}{M_{2} = \left\lbrack {\left( {{gr_{1}} - {gr_{5}}} \right)^{2} + \left( {{gr_{2}} - {gr_{6}}} \right)^{2} + \left( {{gr_{3}} - {gr_{7}}} \right)^{2}} \right\rbrack^{0.5}} & (2)\end{matrix}$

When the derived second metric M₂ satisfies a second predefinedcondition, the application server 114 may detect that the thirdcommunication device 120 is stable. However, when the derived secondmetric M₂ does not satisfy the second predefined condition, theapplication server 114 may detect that the third communication device120 is unstable. In an exemplary scenario, when the derived secondmetric M₂ is less than equal to a second value (i.e., M₂≤m, theapplication server 114 detects that the third communication device 120is stable. However, when the derived second metric M₂ is greater thanthe second value (i.e., M₂>m), the application server 114 detects thatthe third communication device 120 is unstable. The second value may bedetermined by the application server 114 based on historical gravitysensor data collected from various stable and unstable communicationdevices.

At a time-instance, when the third communication device 120 is detectedto be unstable, the application server 114 may be configured to discardthe received target sensor data and wait for target sensor data of asubsequent time-instance. In a non-limiting example, it is assumed thatthe third communication device 120 is detected to be stable. Thus, theapplication server 114 may use the received target sensor data, andprovide the received target sensor data as input to the trained firstprediction model 126 (as shown by arrow 406).

Based on the inputted target sensor data, the trained first predictionmodel 126 may generate an output that indicates a likelihood ofoccurrence of each of the plurality of rash driving events. For example,the generated output may indicate that there is a 10% likelihood ofharsh acceleration, an 80% likelihood of harsh braking, a 90% likelihoodof harsh bump, or the like. Based on the output of the trained firstprediction model 126, the application server 114 may be configured todetect whether any of the plurality of rash driving events has occurredat the current time-instance (as shown by arrow 408). If the likelihoodof occurrence of a rash driving event as determined by the firstprediction model 126 is greater than a threshold value, the applicationserver 114 may detect that the corresponding rash driving event hasoccurred at the current time instance. In one example, the thresholdvalue may be 50%. In this example, the application server 114 may detectthe occurrence of harsh braking and harsh bump events at the currenttime instance. Thus, the application server 114 may tag or mark thecurrent time-instance as a rash driving event for the target vehicle122.

Beneficially, discarding the target sensor data for those time-instanceswhen the third communication device 120 is detected to be unstableenables the application server 114 to ignore false positive rash drivingevents. For example, the third communication device 120 while beinghandled by the target driver 118 may fall and hit the surface of thetarget vehicle 122. If the target sensor data for such time instance isnot discarded, it may lead to the detection of false positive harshacceleration and harsh braking events.

In another embodiment, when the target vehicle 122 is an electricvehicle, the third communication device 120 may further receivereal-time or near real-time sensor data generated by one or more sensorsof a BMS of the target vehicle 122. The received sensor data includesbattery current usage data (i.e., the amount of current being suppliedby) of the batteries of the target vehicle 122. The third communicationdevice 120 may communicate the real-time or near real-time sensor datato the application server 114 by way of the service application. Theapplication server 114 may be configured to receive the sensor datacommunicated by the third communication device 120. Upon receiving thesensor data, the application server 114 may be configured to provide thereceived sensor data as input to the trained second prediction model302. Based on the inputted sensor data, the trained second predictionmodel 302 may generate an output that indicates a likelihood ofoccurrence of each of the plurality of rash driving events. For example,the generated output may indicate that there is a 10% likelihood ofharsh acceleration, an 80% likelihood of harsh braking, a 90% likelihoodof harsh bump, or the like. Based on the output of the trained secondprediction model 302, the application server 114 may be configured todetect whether any of the plurality of rash driving events has occurredat the current time-instance. If the likelihood of occurrence of a rashdriving event as determined by the second prediction model 302 isgreater than the threshold value, the application server 114 may detectthat the corresponding rash driving event has occurred at the currenttime instance. In one example, the threshold value may be 50%. In thisexample, the application server 114 may detect the occurrence of harshbraking and harsh bump events at the current time instance. Thus, theapplication server 114 may tag or mark the current time-instance as arash driving event for the target vehicle 122. In one embodiment, theapplication server 114 may utilize the outputs of the first predictionmodel 126 and the second prediction model 302 collectively to detectwhether any of the plurality of rash driving events has occurred at thecurrent time-instance. In other words, the application server 114 maydetect that a rash driving event has occurred at the currenttime-instance when the outputs of both the first prediction model 126and the second prediction model 302 indicate the occurrence of the rashdriving event.

Upon the detection of the rash driving event, the application server 114may be configured to obtain the operational data of the target vehicle122 and one or more other vehicles that were driven by the target driver118 in the past (as shown by arrow 410). The operational data of avehicle for a driving tenure of a driver may include informationpertaining to odometer readings associated with various trips of thevehicle, repair and maintenance information of the vehicle, vehicle age,vehicle make, historical passenger feedback for the driver driving thevehicle, or the like. In an embodiment, the application server 114 mayobtain the operational data from the third communication device 120. Forexample, the third communication device 120 may be running the serviceapplication that maintains a log or track of various vehicles that havebeen driven by the target driver 118. In another embodiment, theapplication server 114 may obtain a driver profile of the target driver118 from the database server 116 such that the driver profile includesthe operational data of the target vehicle 122 and the other vehiclesthat have been driven by the target driver 118 in the past. In anotherembodiment, the application server 114 may obtain the driver profile ofthe target driver 118 from the corresponding memory.

Based on the operational data, the application server 114 may beconfigured to determine a cumulative distance for which the targetvehicle 122 and the other vehicles have been driven by the target driver118 till the current time-instance (as shown by arrow 412). For example,based on the different odometer readings of the target vehicle 122, theapplication server 114 may determine that till the current time instancethe target vehicle 122 has been driven for 3,000 kilometers by thetarget driver 118. Similarly, the application server 114 may determinethat the target driver 118 had driven another vehicle for 1,000kilometers in the past. Thus, the cumulative distance for which thetarget vehicle 122 and the other vehicles have been driven by the targetdriver 118 is 4,000 kilometers.

With reference to FIG. 4B, the application server 114 may be furtherconfigured to determine a first value of a count of rash driving eventsper unit distance for the target driver 118, till the current timeinstance. For determining the first value, the application server 114may determine a count of rash driving events associated with the targetdriver 118 (as shown by arrow 414). The count of rash driving eventsassociated with the target driver 118 may be determined based on anaggregation of the detected rash driving event at the currenttime-instance and one or more rash driving events associated with thetarget driver 118 in the past. In one example, based on the driverprofile of the target driver 118, the application server 114 maydetermine that the target driver 118 has been involved in ‘19’ rashdriving events in the past. These rash driving events may have beenreported by various passengers travelling with the target driver 118 ordetected based on the application server 114 using the trained firstprediction model 126. Thus, the count of rash driving events associatedwith the target driver 118 is ‘20’. The application server 114 may thendetermine a ratio between the determined count of rash driving eventsand the determined cumulative distance for determining the first valuefor the target driver 118 (i.e., 20/4,000=1 rash driving event per 200kilometers).

The application server 114 may be further configured to determine adriver score of the target driver 118 (as shown by arrow 416). Theapplication server 114 may determine the driver score based on thedetermined first value (i.e., the count of rash driving events per unitdistance) for the target driver 118. The driver score may be a numericalvalue, a percentage value, or a grade that quantifies a quality of thedriving style and behavior of the target driver 118. In an example, thedriver score may lie within a range [0,100] where a driver score of‘100’ represents the best driving style and behavior. For determiningthe driver score, the application server 114 may be configured tocompare the determined first value for the target driver 118 with abaseline criterion. The baseline criterion may have been defined by atransport aggregator associated with the target vehicle 122 or may bedetermined by the application server 114 based on an analysis of aplurality of driver profiles of a plurality of drivers (e.g., the firstand second drivers 102 and 108, or other drivers). For example, thebaseline criterion may be an average count of rash driving events perunit distance of the plurality of drivers that have been characterizedas good drivers based on historical passenger feedback. In one example,the baseline criterion may be one rash driving event per 300 kilometers.In the current example, the application server 114 may determine thatthe target driver 118 has been associated with one rash driving eventper 200 kilometers. Based on the comparison, the application server 114may determine a deviation of the first value from the baselinecriterion. A high deviation from the baseline criterion may result in alow driver score, and vice versa. In one example, if the determinedfirst value is same as (or better than) the baseline criterion, theapplication server 114 may determine the driver score to be 100, i.e.,the highest driver score. With an increase in the deviation from thebaseline criterion, the driver score may tend to decrease. In otherwords, if the count of rash driving events per unit distance of a driveris more than the baseline criterion, the driver score of the driver maybe less than 100 depending upon the deviation. However, if the count ofrash driving events per unit distance of a driver is less than thebaseline criterion, the driver score of the driver may be 100. In anon-limiting example, the driver score of the target driver 118 asdetermined by the application server 114 may be ‘48’.

The application server 114 may be configured communicate the determineddriver score to the database server 116 (as shown by arrow 418). Thedatabase server 116 may be configured to store the determined driverscore in the driver profile of the target driver 118 (as shown by arrow420). Based on the determination of the driver score of the targetdriver 118, the application server 114 may be configured to categorizethe driving style and behavior of the target driver 118 in one of aplurality of driving style categories, e.g., a good driving stylecategory and a bad driving style category (as shown by arrow 422). Eachof the plurality of driving style categories may be associated with adriver score range. In an embodiment, the driver score range associatedwith each driving style category may be defined by the transportaggregator. In another embodiment, the driver score range associatedwith each driving style category may be determined by the applicationserver 114. For example, the driver score range associated with the gooddriving style category may be ‘51-100’ and the driver score rangeassociated with the bad driving style category may be ‘0-50’. Thus, whenthe driver score of the target driver 118 is ‘48’, the applicationserver 114 may categorize the target driver 118 in the bad driving stylecategory.

The application server 114 may be further configured to select one of aplurality of outcomes for the target driver 118 based on the determineddriver score and the detection of the occurrence of rash driving event(as shown by arrow 424). The plurality of outcomes may includeincentivizing the target driver 118 for a high driver score andpenalizing the target driver 118 for a low driver score. The applicationserver 114 may be further configured to communicate an alertnotification to the third communication device 120 of the target driver118 based on the detection of the occurrence of the rash driving eventat the current time instance (as shown by arrow 426). In an embodiment,the application server 114 may communicate the alert notification whenthe determined driver score of the target driver 118 is below athreshold driving score, i.e., when the driving style and behavior ofthe target driver 118 is categorized as in the bad driving stylecategory. In one example, the alert notification may be communicated viaa push notification on the service application running on the thirdcommunication device 120. In another embodiment, the application server114 may communicate the alert notification by way of an interactivevoice response (IVR) call on the third communication device 120.Beneficially, the real-time alert notifications enable the applicationserver 114 to re-shape the substandard driving style and behavior of thetarget driver 118 in real-time towards the optimal driving style andbehavior.

In an embodiment, the application server 114 may be further configuredto generate the driving-pattern profile of the target driver 118 basedon the target sensor data aggregated over a period of time, e.g., oneweek, one month, or the like. In an example, the specific time-intervalmay start when the target driver 118 downloads and installs the serviceapplication hosted by the application server 114 on the thirdcommunication device 120. For example, the target sensor data that isreceived over multiple days may be aggregated to quantify one or moredriver characteristics of the driving style and behavior of the targetdriver 118. The driving-pattern profile may include the one or moredriver characteristics of the target driver 118. For example, the one ormore driver characteristics may include a frequency of braking whiledriving, a braking pattern, a deacceleration pattern, an accelerationrange of the target driver 118, frequently travelled routes, active andinactive hours during a day, or the like. The application server 114 mayutilize the driving-pattern profile to identify if an imposter or anunauthorized driver is driving the target vehicle 122. For example,during a second time-interval, the application server 114 may receivethird sensor data from the third communication device 120. The thirdsensor data may include sensor outputs that indicate a driving patternin which the target vehicle 122 is being driven during the secondtime-interval. The application server 114 may compare the currentdriving pattern with the driving-pattern profile of the target driver118. In a scenario where the current driving pattern is determined to bedifferent from the driving-pattern profile of the target driver 118, theapplication server 114 identifies that the target vehicle 122 is beingdriven by another driver. Thus, the driving-pattern profile may serve asverification data for identity confirmation.

In another embodiment, the application server 114 may be configured torun the trained first prediction model 126 and the trained secondprediction model 302 locally on the third communication device 120 (orother communication devices) by way of the service application installedon the third communication device 120. In such a scenario, when thethird communication device 120 experiences limited or no-networkconnectivity issues, the service application may run in an offline modefor real-time event detection. In such a scenario, the first predictionmodel 126 and the second prediction model 302 that are locally run onthe third communication device 120 detect the occurrence of one or morerash-driving events based on the second sensor data and the batterycurrent usage data, respectively. In one embodiment, the applicationserver 114 may be associated with a transportation service provider,such as a cab service company. In another embodiment, the applicationserver 114 may be associated with a vehicle manufacturing company.

FIG. 5 is a block diagram that illustrates the application server 114,in accordance with an embodiment of the present disclosure. FIG. 5 isdescribed in conjunction with FIGS. 1-4B. The application server 114 mayinclude a network interface 502, processing circuitry 504, a memory 506,an augmentation engine 508, a machine learning engine 510, the firstprediction model 126, and the second prediction model 302. Theapplication server 114 may further include a stability detection engine512, an event detection engine 514, a score determination engine 516, acategorization engine 518, and a driver verification engine 520. Thenetwork interface 502, the processing circuitry 504, the memory 506, theaugmentation engine 508, the machine learning engine 510, the stabilitydetection engine 512, the event detection engine 514, the scoredetermination engine 516, the categorization engine 518, and the driververification engine 520 may communicate with each other by way of one ormore communication buses.

The network interface 502 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry that may beconfigured to enable the application server 114 to communicate with thefirst through third communication devices 104, 110, and 120, and thedatabase server 116. The network interface 502 may be implemented ashardware, software, firmware, or a combination thereof. Examples of thenetwork interface 502 may include a network interface card, a physicalport, a network interface device, an antenna, a radio frequencytransceiver, a wireless transceiver, an Ethernet port, a universalserial bus (USB) port, or the like.

The processing circuitry 504 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry, that may beconfigured to perform various operations for real-time event detectionand driver profiling. The processing circuitry 504 may be configured toperform various operations associated with data collection and dataprocessing. The processing circuitry 504 may be configured to thecontrol and execute the training phase and the implementation phase ofthe application server 114. The processing circuitry 504 may beimplemented by one or more processors, such as, but are not limited to,an application-specific integrated circuit (ASIC) processor, a reducedinstruction set computing (RISC) processor, a complex instruction setcomputing (CISC) processor, and a field-programmable gate array (FPGA)processor. The one or more processors may also correspond to centralprocessing units (CPUs), graphics processing units (GPUs), networkprocessing units (NPUs), digital signal processors (DSPs), or the like.It will be apparent to a person of ordinary skill in the art that theprocessing circuitry 504 may be compatible with multiple operatingsystems.

The memory 506 may include suitable logic, circuitry, and interfacesthat may be configured to store one or more instructions which whenexecuted by the processing circuitry 504 cause the processing circuitry504 to perform various operations for data collection and dataprocessing. The memory 506 may be configured to store the collectedfirst sensor data, the second sensor data, and the third sensor data. Inone embodiment, the memory 506 may be further configured to storevarious driver profiles of drivers (e.g., the first and second drivers102 and 108, and the target driver 118). Examples of the memory 506 mayinclude, but are not limited to, a random access memory (RAM), a readonly memory (ROM), a removable storage drive, a hard disk drive (HDD), aflash memory, a solid-state memory, or the like. It will be apparent toa person skilled in the art that the scope of the disclosure is notlimited to realizing the memory 506 in the application server 114, asdescribed herein. In another embodiment, the memory 506 may be realizedin form of the database server 116 or a cloud storage working inconjunction with the application server 114, without departing from thescope of the disclosure.

The augmentation engine 508 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry, that may beconfigured to augment the collected first sensor data based on randomangular rotation (as described in the foregoing description of FIG. 3).For augmenting the collected first sensor data, the augmentation engine508 may be configured to generate the 3D rotation matrix (R_((N×3))) andapply the generated 3D rotation matrix (R_((N×3))) to each sensor outputin the first sensor data to obtain the plurality of augmented sensoroutputs. The augmentation engine 508 may be implemented by one or moreprocessors, such as, but are not limited to, an ASIC processor, a RISCprocessor, a CISC processor, and an FPGA processor. The one or moreprocessors may also correspond to CPUs, GPUs, NPUs, DSPs, or the like.It will be apparent to a person of ordinary skill in the art that theaugmentation engine 508 may be compatible with multiple operatingsystems.

The machine learning engine 510 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry, that may beconfigured to perform one or more operations for training the firstprediction model 126 using the plurality of augmented sensor outputs andthe second prediction model 302 using the battery current usage data.The machine learning engine 510 may implement any suitablemachine-learning techniques, statistical techniques, deep learning, orprobabilistic techniques for training of the first prediction model 126and the second prediction model 302. The machine learning engine 510 maytrain the first prediction model 126 to correlate the plurality of rashdriving events with the plurality of augmented sensor outputs. Themachine learning engine 510 may train the second prediction model 302 tocorrelate the plurality of rash driving events with the battery currentusage data. The machine learning engine 510 may be implemented by one ormore processors, such as, but are not limited to, an ASIC processor, aRISC processor, a CISC processor, and an FPGA processor. The one or moreprocessors may also correspond to CPUs, GPUs, NPUs, DSPs, or the like.It will be apparent to a person of ordinary skill in the art that themachine learning engine 510 may be compatible with multiple operatingsystems.

The stability detection engine 512 may include suitable logic,circuitry, interfaces, and/or code, executable by the circuitry, thatmay be configured to perform one or more operations for detectingwhether the third communication device 120, from which the target sensordata (i.e., the second sensor data) is received, is stable or unstable.The stability detection engine 512 may be configured to utilize andprocess various sensor outputs generated by a gyroscope sensor or agravity sensor for stability and instability detection (as described inthe foregoing description of FIGS. 4A and 4B). The stability detectionengine 512 may be configured to provide sensor data to the trained firstprediction model 126 as input only when the sensor data is associatedwith a stable device. In other words, the stability detection engine 512skips event detection at those time-instances when a communicationdevice, from which sensor data is received, is detected to be unstable.The stability detection engine 512 may be implemented by one or moreprocessors, such as, but are not limited to, an ASIC processor, a RISCprocessor, a CISC processor, and an FPGA processor. The one or moreprocessors may also correspond to CPUs, GPUs, NPUs, DSPs, or the like.It will be apparent to a person of ordinary skill in the art that thestability detection engine 512 may be compatible with multiple operatingsystems.

The event detection engine 514 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry, that may beconfigured to perform one or more operations for rash driving eventdetection. The event detection engine 514 may be configured to detectwhether a rash driving event has occurred for the target vehicle 122based on the output of the trained first prediction model 126 (asdescribed in the foregoing description of FIGS. 4A and 4B). The eventdetection engine 514 may be implemented by one or more processors, suchas, but are not limited to, an ASIC processor, a RISC processor, a CISCprocessor, and an FPGA processor. The one or more processors may alsocorrespond to CPUs, GPUs, NPUs, DSPs, or the like. It will be apparentto a person of ordinary skill in the art that the event detection engine514 may be compatible with multiple operating systems.

The score determination engine 516 may include suitable logic,circuitry, interfaces, and/or code, executable by the circuitry, thatmay be configured to perform one or more operations for determiningdriver score of drivers. The score determination engine 516 may beconfigured to determine the baseline criterion based on the analysis ofthe plurality of driver profiles of the plurality of drivers. The scoredetermination engine 516 may be further configured to determine thefirst value for the target driver 118 based on the cumulative distancedriven by the target driver 118 and the count of rash driving eventsassociated with the target driver 118 (as described in the foregoingdescription of FIG. 4B). The score determination engine 516 may beimplemented by one or more processors, such as, but are not limited to,an ASIC processor, a RISC processor, a CISC processor, and an FPGAprocessor. The one or more processors may also correspond to CPUs, GPUs,NPUs, DSPs, or the like. It will be apparent to a person of ordinaryskill in the art that the score determination engine 516 may becompatible with multiple operating systems.

The categorization engine 518 may include suitable logic, circuitry,interfaces, and/or code, executable by the circuitry, that may beconfigured to categorize the driving style and behavior of the targetdriver 118 in one of the plurality of driving style categories based onthe determined driver score of the target driver 118. Examples of thecategorization engine 518 may include, but are not limited to, an ASICprocessor, a RISC processor, a CISC processor, and an FPGA processor.The categorization engine 518 may also correspond to a CPU, a GPU, anNPU, a DSP, or the like. It will be apparent to a person of ordinaryskill in the art that the categorization engine 518 may be compatiblewith multiple operating systems.

The driver verification engine 520 may include suitable logic,circuitry, interfaces, and/or code, executable by the circuitry, thatmay be configured to generate driving-pattern profiles of variousdrivers based on sensor data accumulated during driving trips of thecorresponding drivers. The driver verification engine 520 may be furtherconfigured to determine whether an authorized driver (i.e., the targetdriver 118) is driving a vehicle (e.g., the target vehicle 122) bycomparing the driver-pattern profile of the authorized driver with acurrent driving pattern associated with the vehicle. Examples of thedriver verification engine 520 may include, but are not limited to, anASIC processor, a RISC processor, a CISC processor, and an FPGAprocessor. The driver verification engine 520 may also correspond to aCPU, a GPU, an NPU, a DSP, or the like. It will be apparent to a personof ordinary skill in the art that the driver verification engine 520 maybe compatible with multiple operating systems

Although the processing circuitry 504, the augmentation engine 508, themachine learning engine 510, the stability detection engine 512, theevent detection engine 514, the score determination engine 516, thecategorization engine 518, and the driver verification engine 520 areshown as standalone components of the application server 114, the scopeof the disclosure is not limited to it. In another embodiment, theprocessing circuitry 504 may be integrated with the functionalities ofthe augmentation engine 508, the machine learning engine 510, thestability detection engine 512, the event detection engine 514, thescore determination engine 516, the categorization engine 518, and thedriver verification engine 520.

FIG. 6A is a flow chart 600 that illustrates a method for training thefirst prediction model 126 for real-time rash driving event detection,in accordance with an exemplary embodiment of the disclosure. The flowchart 600 represents the training phase of the application server 114during which the first prediction model 126 is trained.

At 602, the first sensor data generated by various sensors associatedwith a plurality of vehicles (e.g., the first and second vehicles 106and 112) is collected. The application server 114 may be configured tocollect the first sensor data generated by the sensors associated withthe first and second vehicles 106 and 112. The first sensor data may bereceived from the first and second communication devices 104 and 110present within the respective first and second vehicles 106 and 112, viathe communication network 124. The first sensor data may include thefirst plurality of sensor outputs (i.e. the acceleration data, thegravity sensor data, the gyroscopic data, the altimeter data, and/or themagnetometer data) that indicate the plurality of rash driving events.

At 604, the first plurality of sensor outputs are augmented based onangular rotation to obtain the plurality of augmented sensor outputs.The application server 114 may be configured to augment the firstplurality of sensor outputs to obtain the plurality of augmented sensoroutputs. The method of augmenting the first plurality of sensor outputsis described in conjunction with FIG. 6B.

Referring now to FIG. 6B, a sub flow chart 604 that illustrates themethod for augmenting the first plurality of sensor outputs inaccordance with an exemplary embodiment of the disclosure, is shown. At604 a, the 3D rotation matrix (R_((N×3))) for random angular rotation isgenerated. The application server 114 may be configured to generate the3D rotation matrix (R_((N×3))). At 604 b, the 3D rotation matric(R_((N×3))) is applied to the first plurality of sensor outputs. Theapplication server 114 may be configured to apply the 3D rotation matric(R_((N×3))) to the first plurality of sensor outputs for the angularrotation of the first plurality of sensor outputs. The first pluralityof sensor outputs after the angular rotation correspond to the pluralityof augmented sensor outputs.

Referring back to FIG. 6A, at 606, the first prediction model 126 may betrained based on the plurality of augmented sensor outputs. Theapplication server 114 may be configured to train the first predictionmodel 126 based on the plurality of augmented sensor outputs. Thetrained first prediction model 126 may be validated by the applicationserver 114 for improving the accuracy level of the first predictionmodel 126.

FIGS. 7A and 7B collectively, represent a flow chart 700 for augmentingtransport services using real-time event detection, in accordance withan embodiment of the present disclosure.

At 702, real-time or near real-time target sensor data generated bysensors associated with the target vehicle 122 is received. Theapplication server 114 may be configured to receive the target sensordata generated by the sensors associated with the target vehicle 122 inreal-time or near real-time. The sensors associated with the targetvehicle 122 may be included in the third communication device 120 thatis present inside the target vehicle 122, while the target vehicle 122is being driven by the target driver 118. The target sensor data mayinclude the second plurality of sensor outputs that indicate the drivingpattern of the target driver 118 driving the target vehicle 122 at thefirst time-instance. The second plurality of sensor outputs maycorrespond to a plurality of sequential time-instances. Each sensoroutput may have 3-axes sensor values. For example, a sensor output froma gyroscopic sensor may have a 3-axes value, G (g₁, g₂, g₃).

At 704, the application server 114 may be configured to detect whetherthe third communication device 120 is stable or unstable based on thereceived target sensor data (as described in the foregoing descriptionof FIG. 4A). If at 704, the application server 114 detects that thethird communication device 120 is unstable, the application server 114discards the received target sensor data, and 702 is executed. If at704, the application server 114 detects that the third communicationdevice 120 is stable, 706 is executed.

At 706, the received target sensor data is provided as input to thetrained first prediction model 126 based on the detection that the thirdcommunication device 120 is stable. The application server 114 may beconfigured to provide the received target sensor data as input to thetrained first prediction model 126 when the third communication device120 is detected to be stable. At 708, an occurrence of one of theplurality of rash driving events at the first time-instance is detectedbased on the output of the trained first prediction model 126 for theinputted target sensor data. The application server 114 may beconfigured to detect the occurrence of one of the plurality of rashdriving events at the first time-instance based on the output of thetrained first prediction model 126.

At 710, the operational data of the target vehicle 122 is obtained. Theapplication server 114 may be configured to obtain the operational dataof the target vehicle 122 and one or more other vehicles that weredriven by the target driver 118 in the past. The operational data isindicative of the cumulative distance that the target vehicle 122 andthe one or more other vehicles are driven by the target driver 118 untilthe first time-instance.

At 712, the driver score of the target driver 118 is determined based onthe count of rash driving events associated with the target driver 118within the cumulative distance. The application server 114 may beconfigured to determine the driver score of the target driver 118 basedon the count of rash driving events associated with the target driver118 within the cumulative distance.

At 714, the determined driver score is communicated to the databaseserver 116. The application server 114 may be configured to communicatethe determined driver score to the database server 116. As 716, thedriving style and behavior of the target driver 118 is categorized inone of the plurality of driving style categories based on the determineddriver score. The application server 114 may be configured to categorizethe driving style and behavior of the target driver 118 in one of theplurality of driving style categories, e.g., the good driving stylecategory and the bad driving style category. At 718, one of theplurality of outcomes for the target driver 118 is selected based on thedetermined driver score and the detection of the occurrence of rashdriving event. The application server 114 may be configured to selectone of the plurality of outcomes for the target driver 118 based on thedetermined driver score and the detection of the occurrence of rashdriving event. The plurality of outcomes may include incentivizing thetarget driver 118 for a high driver score and penalizing the targetdriver 118 for a low driver score. At 720, an alert notification iscommunicated to the third communication device 120 of the target driver118 based on the detection of the occurrence of the rash driving eventat the current time instance. The application server 114 may beconfigured to communicate the alert notification to the thirdcommunication device 120 of the target driver 118 when the determineddriver score of the target driver 118 is below a threshold drivingscore, i.e., when the driving style and behavior of the target driver118 is categorized as in the bad driving style category.

FIG. 8 represents a flow chart 800 that illustrates a method ofauthenticating a driver of a vehicle, in accordance with an embodimentof the present disclosure.

At 802, target sensor data generated by the sensors associated with thetarget vehicle 122 is aggregated over a period of time. The applicationserver 114 may be further configured to aggregate the target sensor datagenerated by the third communication device 120 present in the targetvehicle 122. At 804, the driving-pattern profile of the target driver118 is generated based on the aggregated target sensor data. Theapplication server 114 may be configured to generate the driving-patternprofile of the target driver 118. At 806, new sensor data, generated bythe sensors associated with the target vehicle 122, is received. Theapplication server 114 may be further configured to receive the newsensor data generated by the third communication device 120 when thetarget vehicle 122 is driven or when a trip on the target vehicle 122 isinitiated.

At 808, the application server 114 may be configured to compare thedriving pattern indicated by the new sensor data with thedriving-pattern profile of the target driver 118. At 810, theapplication server 114 may be configured to authenticate the targetdriver 118 based on a match between the driving pattern indicated by thenew sensor data and the driving-pattern profile of the target driver118. In other words, based on the comparing of the driving patternindicated by the new sensor data with the driving-pattern profile of thetarget driver 118, the application server 114 identifies whether thetarget vehicle 122 is being driven by the target driver 118 or anotherdriver.

FIG. 9 is a flow chart 900 that illustrates a method for training thesecond prediction model 302 for real-time rash driving event detection,in accordance with an exemplary embodiment of the disclosure. The flowchart 900 represents the training phase of the application server 114during which the second prediction model 302 is trained.

At 902, sensor data generated by various sensors associated with aplurality of vehicles (e.g., the first and second vehicles 106 and 112)is collected. The collected sensor data includes battery current usagedata associated with the plurality of rash driving events. The sensordata may be collected by the application server 114 from the first andsecond communication devices 104 and 110 present within the respectivefirst and second vehicles 106, via the communication network 124. Thesensor data may be generated by the sensors associated with the BMSs ofthe first and second vehicles 106 and 112 based on the amount of currentbeing supplied by the batteries of the first and second vehicles 106 and112 for the functioning of the first and second vehicles 106 and 112.

At 904, the second prediction model 302 is trained based on thecollected sensor data. The application server 114 may be configured totrain the second prediction model 302 based on the collected sensordata. The trained second prediction model 302 may be validated by theapplication server 114 for improving the accuracy level of the secondprediction model 302.

FIGS. 10A and 10B collectively, represent a flow chart 1000 foraugmenting transport services using real-time event detection, inaccordance with an embodiment of the present disclosure.

At 1002, real-time or near real-time target sensor data generated bysensors associated with the target vehicle 122 is received. Theapplication server 114 may be configured to receive the target sensordata generated by the sensors associated with the target vehicle 122 inreal-time or near real-time. The sensors associated with the targetvehicle 122 may be included in the BMS of the target vehicle 122. Thetarget sensor data may include battery current usage data of the targetvehicle 122 at the first time-instance. The battery current usage dataof the target vehicle 122 indicates the amount of current being suppliedby the battery of the target vehicle 122 for the functioning of thetarget vehicle 122.

At 1004, the received target sensor data is provided as input to thetrained second prediction model 302. At 1006, an occurrence of one ofthe plurality of rash driving events at the first time-instance isdetected based on the output of the trained second prediction model 302for the inputted target sensor data. The application server 114 may beconfigured to detect the occurrence of one of the plurality of rashdriving events at the first time-instance based on the output of thetrained second prediction model 302.

At 1008, the operational data of the target vehicle 122 is obtained. Theapplication server 114 may be configured to obtain the operational dataof the target vehicle 122 and one or more other vehicles that weredriven by the target driver 118 in the past. The operational data isindicative of the cumulative distance that the target vehicle 122 andthe one or more other vehicles are driven by the target driver 118 untilthe first time-instance.

At 1010, the driver score of the target driver 118 is determined basedon the count of rash driving events associated with the target driver118 within the cumulative distance. The application server 114 may beconfigured to determine the driver score of the target driver 118 basedon the count of rash driving events associated with the target driver118 within the cumulative distance.

At 1012, the determined driver score is communicated to the databaseserver 116. The application server 114 may be configured to communicatethe determined driver score to the database server 116. As 1014, thedriving style and behavior of the target driver 118 is categorized inone of the plurality of driving style categories based on the determineddriver score. The application server 114 may be configured to categorizethe driving style and behavior of the target driver 118 in one of theplurality of driving style categories, e.g., the good driving stylecategory and the bad driving style category. At 1016, one of theplurality of outcomes for the target driver 118 is selected based on thedetermined driver score and the detection of the occurrence of rashdriving event. The application server 114 may be configured to selectone of the plurality of outcomes for the target driver 118 based on thedetermined driver score and the detection of the occurrence of rashdriving event. The plurality of outcomes may include incentivizing thetarget driver 118 for a high driver score and penalizing the targetdriver 118 for a low driver score. At 1018, an alert notification iscommunicated to the third communication device 120 of the target driver118 based on the detection of the occurrence of the rash driving eventat the current time instance. The application server 114 may beconfigured to communicate the alert notification to the thirdcommunication device 120 of the target driver 118 when the determineddriver score of the target driver 118 is below a threshold drivingscore, i.e., when the driving style and behavior of the target driver118 is categorized as in the bad driving style category.

FIG. 11 is a block diagram that illustrates a system architecture of acomputer system for augmenting transport services using real-time eventdetection, in accordance with an exemplary embodiment of the disclosure.An embodiment of the disclosure, or portions thereof, may be implementedas computer readable code on the computer system 1100. In one example,the application server 114 and the database server 116 may beimplemented in the computer system 1100 using hardware, software,firmware, non-transitory computer readable media having instructionsstored thereon, or a combination thereof and may be implemented in oneor more computer systems or other processing systems. Hardware,software, or any combination thereof may embody modules and componentsused to implement the methods of FIGS. 6A-6B, 7A-7B, 8, 9, and 10A-10B.

The computer system 1100 may include a processor 1102 that may be aspecial purpose or a general-purpose processing device. The processor1102 may be a single processor or multiple processors. The processor1102 may have one or more processor “cores.” Further, the processor 1102may be coupled to a communication infrastructure 1104, such as a bus, abridge, a message queue, the communication network 124, multi-coremessage-passing scheme, or the like. The computer system 1100 mayfurther include a main memory 1106 and a secondary memory 1108. Examplesof the main memory 1106 may include RAM, ROM, and the like. Thesecondary memory 1108 may include a hard disk drive or a removablestorage drive (not shown), such as a floppy disk drive, a magnetic tapedrive, a compact disc, an optical disk drive, a flash memory, or thelike. Further, the removable storage drive may read from and/or write toa removable storage device in a manner known in the art. In anembodiment, the removable storage unit may be a non-transitory computerreadable recording media.

The computer system 1100 may further include an input/output (I/O) port1110 and a communication interface 1112. The I/O port 1110 may includevarious input and output devices that are configured to communicate withthe processor 1102. Examples of the input devices may include akeyboard, a mouse, a joystick, a touchscreen, a microphone, and thelike. Examples of the output devices may include a display screen, aspeaker, headphones, and the like. The communication interface 1112 maybe configured to allow data to be transferred between the computersystem 1100 and various devices that are communicatively coupled to thecomputer system 1100. Examples of the communication interface 1112 mayinclude a modem, a network interface, i.e., an Ethernet card, acommunication port, and the like. Data transferred via the communicationinterface 1112 may be signals, such as electronic, electromagnetic,optical, or other signals as will be apparent to a person skilled in theart. The signals may travel via a communications channel, such as thecommunication network 124, which may be configured to transmit thesignals to the various devices that are communicatively coupled to thecomputer system 1100. Examples of the communication channel may includea wired, wireless, and/or optical medium such as cable, fiber optics, aphone line, a cellular phone link, a radio frequency link, and the like.The main memory 1106 and the secondary memory 1108 may refer tonon-transitory computer readable mediums that may provide data thatenables the computer system 1100 to implement the methods illustrated inFIGS. 6A-6B, 7A-7B, 8, 9 and 10A-10B.

Various embodiments of the disclosure provide the application server 114for augmenting transport services using event detection. The applicationserver 114 may be configured to collect the first sensor data generatedby a plurality of sensors associated with a plurality of vehicles (e.g.,the vehicles 106 and 112). The first sensor data includes the firstplurality of sensor outputs that indicate the plurality of rash drivingevents. The application server 114 may be further configured to augmentthe first plurality of sensor outputs based on angular rotation toobtain the plurality of augmented sensor outputs. The application server114 may be further configured to train the first prediction model 126based on the plurality of augmented sensor outputs. The applicationserver 114 may be further configured to receive, in real-time or nearreal-time, the target sensor data generated by one or more sensorsassociated with the target vehicle 122. The target sensor data includesthe second plurality of sensor outputs that indicate a driving patternof the target driver 118 driving the target vehicle 122 at the firsttime-instance. The application server 114 may be further configured toprovide the target sensor data to the trained prediction model 126 as aninput and detect an occurrence of at least one of the plurality of rashdriving events at the first time-instance based on an output of thetrained prediction model 126 for the inputted target sensor data.

Various embodiments of the disclosure provide the application server 114for augmenting transport services using event detection. The applicationserver 114 may be configured to collect the sensor data generated by aplurality of sensors associated with a plurality of vehicles (e.g., thevehicles 106 and 112). The collected sensor data includes at least firstbattery current usage data associated with the plurality of rash drivingevents. The application server 114 may be further configured to trainthe second prediction model 302 based on the collected sensor data. Theapplication server 114 may be further configured to receive, inreal-time or near real-time, the target sensor data generated by one ormore sensors associated with the target vehicle 122. The target sensordata includes the second battery current usage data of the targetvehicle 122 at the first time-instance. The application server 114 maybe further configured to provide the target sensor data to the trainedprediction model 302 as an input and detect an occurrence of at leastone of the plurality of rash driving events at the first time-instancebased on an output of the trained prediction model 302 for the inputtedtarget sensor data.

Various embodiments of the disclosure provide a non-transitorycomputer-readable medium having stored thereon, computer executableinstructions, which when executed by a computer, cause the computer toexecute operations for augmenting transport services using eventdetection. The operations include collecting, by the application server114, the first sensor data generated by the plurality of sensorsassociated with a plurality of vehicles (e.g., the vehicles 106 and112). The first sensor data includes the first plurality of sensoroutputs that indicate the plurality of rash driving events. Theoperations further include augmenting, by the application server 114,the first plurality of sensor outputs based on angular rotation toobtain the plurality of augmented sensor outputs. The operations furtherinclude training, by the application server 114, the prediction model126 based on the plurality of augmented sensor outputs. The operationsfurther include receiving, by the application server 114, in real-timeor near real-time, the target sensor data generated by one or moresensors associated with the target vehicle 122. The target sensor dataincludes the second plurality of sensor outputs that indicate a drivingpattern of the target driver 118 driving the target vehicle 122 at thefirst time-instance. The operations further include providing, by theapplication server 114, the target sensor data to the trained predictionmodel 126 as an input. The operations further include detecting, by theapplication server 114, an occurrence of at least one of the pluralityof rash driving events at the first time-instance based on an output ofthe trained prediction model 126 for the inputted target sensor data.

Various embodiments of the disclosure provide a non-transitorycomputer-readable medium having stored thereon, computer executableinstructions, which when executed by a computer, cause the computer toexecute operations for augmenting transport services using eventdetection. The operations include collecting, by the application server114, the sensor data generated by the plurality of sensors associatedwith a plurality of vehicles (e.g., the vehicles 106 and 112). Thecollected sensor data includes the first battery current usage dataassociated with the plurality of rash driving events. The operationsfurther include training, by the application server 114, the predictionmodel 302 based on the collected sensor data. The operations furtherinclude receiving, by the application server 114, in real-time or nearreal-time, the target sensor data generated by one or more sensorsassociated with the target vehicle 122. The target sensor data includesthe second battery current usage data of the target vehicle 122 at thefirst time-instance. The operations further include providing, by theapplication server 114, the target sensor data to the trained predictionmodel 302 as an input. The operations further include detecting, by theapplication server 114, an occurrence of at least one of the pluralityof rash driving events at the first time-instance based on an output ofthe trained prediction model 302 for the inputted target sensor data.

Technological improvements in the application server 114 enable theapplication server 114 to detect occurrences of rash driving events onreal-time or near real-time basis. The application server 114 leveragesthe sensor data generated by various sensors of a mobile device that ispresent inside the vehicle to detect a rash driving event for a vehicle.In other words, sensor data generated by a smartphone or a mobile phoneof a driver may be utilized to detect any rash driving event caused bythe driver. Thus, the application server 114 eliminates the requirementof equipping the vehicle with expensive specialized hardware. Further,the training of the first prediction model 126 is generalized tocompensate for any angular orientation of the mobile device. Thus, theposition or angular orientation of the mobile device generating sensordata does not affect the accuracy of the first prediction model 126.Further, the application server 114 skips event detection for those timeinstances when the mobile device generating the sensor data is unstable,thereby reducing the likelihood of false positive event detection. Thus,the method and system of the present disclosure enable rash drivingevent detection for all types of vehicles. Further, based on the rashdriving event detection, drivers are categorized and real time alertsand warnings are communicated to the drivers. Such real time alerts andwarnings enable reshaping of substandard driving styles to optimaldriving styles. Thus, the methods and systems of the present disclosureare not only capable of detecting rash driving events but alsocorrecting substandard driving styles of drivers on real-time or nearreal-time basis. Due to improvement in driving styles of drivers,transport services offered by a transport service aggregator areaugmented and travel experience of the passengers is improved.

A person of ordinary skill in the art will appreciate that embodimentsand exemplary scenarios of the disclosed subject matter may be practicedwith various computer system configurations, including multi-coremultiprocessor systems, minicomputers, mainframe computers, computerslinked or clustered with distributed functions, as well as pervasive orminiature computers that may be embedded into virtually any device.Further, the operations may be described as a sequential process,however some of the operations may in fact be performed in parallel,concurrently, and/or in a distributed environment, and with program codestored locally or remotely for access by single or multiprocessormachines. In addition, in some embodiments, the order of operations maybe rearranged without departing from the spirit of the disclosed subjectmatter.

Techniques consistent with the disclosure provide, among other features,systems and methods for augmenting transport services using real-timeevent detection. While various exemplary embodiments of the disclosedsystems and methods have been described above, it should be understoodthat they have been presented for purposes of example only, and notlimitations. It is not exhaustive and does not limit the disclosure tothe precise form disclosed. Modifications and variations are possible inlight of the above teachings or may be acquired from practicing of thedisclosure, without departing from the breadth or scope.

While various embodiments of the disclosure have been illustrated anddescribed, it will be clear that the disclosure is not limited to theseembodiments only. Numerous modifications, changes, variations,substitutions, and equivalents will be apparent to those skilled in theart, without departing from the spirit and scope of the disclosure, asdescribed in the claims.

What is claimed is:
 1. A method, comprising: collecting, by anapplication server, first sensor data generated by a plurality ofsensors associated with a plurality of vehicles, wherein the firstsensor data includes a first plurality of sensor outputs that indicate aplurality of rash driving events; augmenting, by the application server,the first plurality of sensor outputs based on angular rotation toobtain a plurality of augmented sensor outputs; training, by theapplication server, a prediction model based on the plurality ofaugmented sensor outputs; receiving, by the application server, inreal-time or near real-time, target sensor data generated by one or moresensors associated with a target vehicle, wherein the target sensor dataincludes a second plurality of sensor outputs that indicate a firstdriving pattern of a target driver driving the target vehicle at a firsttime-instance; providing, by the application server, the target sensordata to the trained prediction model as an input; and detecting, by theapplication server, an occurrence of at least one of the plurality ofrash driving events at the first time-instance based on an output of thetrained prediction model for the inputted target sensor data.
 2. Themethod of claim 1, wherein the first sensor data and the target sensordata include at least one of acceleration data, gravity sensor data,gyroscopic data, and magnetometer data.
 3. The method of claim 1,wherein the plurality of rash driving events include at least one of aharsh braking event, a harsh cornering event, a harsh accelerationevent, a harsh bump event, a tailgating event, and an over-speedingevent.
 4. The method of claim 1, wherein each sensor output of the firstsensor data and each sensor output of the target sensor data includesthree axes sensor values along first through third axis, respectively.5. The method of claim 4, wherein augmenting the first plurality ofsensor outputs comprises: generating, by the application server, a3-dimensional (3D) rotation matrix for random angular rotation along thefirst through third axis; and applying, by the application server, the3D rotation matrix to the first plurality of sensor outputs for theangular rotation of the first plurality of sensor outputs, wherein thefirst plurality of sensor outputs after the angular rotation correspondto the plurality of augmented sensor outputs.
 6. The method of claim 1,wherein the one or more sensors associated with the target vehicle areincluded in a mobile device that is present inside the target vehiclewhile the target vehicle is driven by the target driver.
 7. The methodof claim 6, further comprising detecting, by the application server,whether the mobile device is stable or unstable based on the targetsensor data, wherein the target sensor data is provided to the trainedprediction model based on the detection that the mobile device isstable.
 8. The method of claim 1, further comprising: determining, bythe application server, a count of rash driving events associated withthe target driver until the first time-instance, wherein the count ofrash driving events is determined based on an aggregation of thedetected rash driving event at the first time-instance and one or morerash driving events associated with the target driver in the past;obtaining, by the application server, operational data of the targetvehicle and one or more other vehicles driven by the target driver inthe past, wherein the operational data indicates a cumulative distancethat the target vehicle and the one or more other vehicles are driven bythe target driver until the first time-instance; and determining, by theapplication server, a driver score for the target driver based on atleast the determined count of rash driving events within the cumulativedistance.
 9. The method of claim 8, further comprising selecting, by theapplication server, one of a plurality of outcomes for the target driverbased on the determined driver score and the detection of the occurrenceof at least one of the plurality of rash driving events, wherein theplurality of outcomes include at least incentivizing the target driverand penalizing the target driver.
 10. The method of claim 8, furthercomprising categorizing, by the application server, a driving style ofthe target driver in one of a plurality of driving style categoriesbased on the determined driver score of the target driver.
 11. Themethod of claim 8, further comprising communicating, by the applicationserver, an alert notification to a communication device of the targetdriver based on the detection of the occurrence of at least one of theplurality of rash driving events, wherein the alert notification iscommunicated when the driver score of the target driver is below athreshold driving score.
 12. The method of claim 1, further comprising:generating, by the application server, a driving-pattern profile of thetarget driver based on at least the received target sensor data;receiving, by the application server, third sensor data from the one ormore sensors associated with the target vehicle, wherein the thirdsensor data includes a third plurality of sensor outputs that indicate asecond driving pattern; and identifying, by the application server,whether the target vehicle is driven by the target driver or anunauthorized driver based on a comparison of the generateddriving-pattern profile and the second driving pattern indicated by thethird sensor data.
 13. A system, comprising: an application serverconfigured to: collect first sensor data from a plurality of sensorsassociated with a plurality of vehicles, wherein the first sensor dataincludes a first plurality of sensor outputs that indicate a pluralityof rash driving events; augment the first plurality of sensor outputsbased on angular rotation to obtain a plurality of augmented sensoroutputs; train a prediction model based on the plurality of augmentedsensor outputs; receive, in real-time or near real-time, target sensordata from one or more sensors associated with a target vehicle, whereinthe target sensor data includes a second plurality of sensor outputsthat indicate a driving pattern of a target driver of the target vehicleat a first time-instance; provide the target sensor data to the trainedprediction model as an input; and detect an occurrence of at least oneof the plurality of rash driving events at the first time-instance basedon an output of the trained prediction model for the inputted targetsensor data.
 14. The system of claim 13, wherein each sensor output ofthe first sensor data and each sensor output of the target sensor dataincludes three axes sensor values along first through third axis,respectively, and wherein to augment the first plurality of sensoroutputs, the application server is further configured to: generate a3-dimensional (3D) rotation matrix for random angular rotation along thefirst through third axis; and apply the 3D rotation matrix to the firstplurality of sensor outputs for the angular rotation of the firstplurality of sensor outputs, wherein the first plurality of sensoroutputs after the angular rotation correspond to the plurality ofaugmented sensor outputs.
 15. The system of claim 13, wherein the one ormore sensors associated with the target vehicle are included in a mobiledevice that is present inside the target vehicle, and wherein theapplication server is further configured to: detect whether the mobiledevice is stable or unstable based on the target sensor data, whereinthe target sensor data is provided to the trained prediction model basedon the detection that the mobile device is stable.
 16. The system ofclaim 13, wherein the application server is further configured to:determine a count of rash driving events associated with the targetdriver of the target vehicle by the first time-instance, wherein thecount of rash driving events is determined based on an aggregation ofthe detected rash driving event at the first time-instance and one ormore rash driving events associated with the driver in the past; receiveoperational data of the target vehicle and one or more other vehiclesdriven by the target driver in the past, wherein the operational dataindicates a cumulative distance that the target vehicle and the one ormore other vehicles are driven by the target driver until the firsttime-instance; determine a driver score for the target driver based onat least the determined count of rash driving events within thecumulative distance; and categorize a driving style of the target driverin one of a plurality of driving style categories based on thedetermined driver score of the target driver.
 17. The system of claim16, wherein the application server is further configured to select oneof a plurality of outcomes for the target driver based on the determineddriver score and the detection of the occurrence of at least one of theplurality of rash driving events, and wherein the plurality of outcomesinclude at least incentivizing the target driver and penalizing thetarget driver.
 18. The system of claim 17, wherein the applicationserver is further configured to communicate an alert notification to acommunication device of the target driver based on the detection of theoccurrence of at least one of the plurality of rash driving events, andwherein the alert notification is communicated when the driver score ofthe target driver is above a threshold driving score.
 19. The system ofclaim 13, wherein the plurality of rash driving events include at leastone of a harsh braking event, a harsh cornering event, a harshacceleration event, a harsh bump event, a tailgating event, and anover-speeding event.
 20. A method, comprising: collecting, by anapplication server, sensor data generated by a plurality of sensorsassociated with a plurality of vehicles, wherein the collected sensordata includes at least first battery current usage data associated witha plurality of rash driving events; training, by the application server,a prediction model based on the collected sensor data; receiving, by theapplication server, in real-time or near real-time, target sensor datagenerated by one or more sensors associated with a target vehicle,wherein the target sensor data includes second battery current usagedata of the target vehicle at a first time-instance; providing, by theapplication server, the target sensor data to the trained predictionmodel as an input; and detecting, by the application server, anoccurrence of at least one of the plurality of rash driving events atthe first time-instance based on an output of the trained predictionmodel for the inputted target sensor data.